home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ 4⁄27⁄90 / 1196-The Great GC Debate -Apr90 < prev    next >
Encoding:
Text File  |  1990-04-27  |  1.9 KB  |  42 lines  |  [TEXT/GEOL]
  1. Item forwarded  by  A33          to A34
  2.  
  3. Item    8136051                         24-April-90        14:43PDT
  4.  
  5. From:   PASCOE1                         Pascoe, Geoff
  6.  
  7. To:     MACAPP.TECH$                    MacApp Technical
  8.  
  9. Sub:    The Great GC Debate Continues
  10.  
  11. Jeff,
  12.  
  13. It sounds like you and your group really have your act together if the addition
  14. of GC didn't cause changes to your application-level source (am I reading you
  15. right?).  With regard to slipping in new memory management strategies- I can
  16. see how C++ would allow you to tune different classes to use different
  17. strategies, but I have a few questions:
  18.  
  19. 1) Assuming that your entire system uses the same memory management strategy,
  20. doesn't simple procedure abstraction (designed properly) allow you to "slip
  21. in" a new strategy when appropriate.  That is, under this case I can't see a
  22. whole lot that C++ buys you.  At least in this area.
  23.  
  24. 2) Assuming that you use different memory management strategies for different
  25. classes (overloading in C++ does provide benefits here), don't you forsee
  26. conflicts between classes that have references to each but use different memory
  27. management strategies?  I know (or, used to know), quite a bit about GC
  28. (generation scavenging in particular) and it seems to me that GC's, in general,
  29. and generation scavenging, in particular, don't deal well with object
  30. references outside their domain.  At the very least, the algorithms would be
  31. "significantly" complicated because of special cases.
  32.  
  33. 3) Specifically, what are the features of C++ over a minimalist Object Pascal
  34. that let's you do this in C++ but not Object Pascal?  I'm looking for the
  35. distilled essence here.  I think I know some of them, but I'd like to here it
  36. from somebody that's actually done it.  This data could be very valuable to
  37. Derek White (he's now designing the new Object Pascal).  Maybe we can make an
  38. Object Pascal that has lot's of advantages, but without the baggage.
  39.  
  40. Geoff
  41.  
  42.